\section{Test of \ac{RLNC} with \ac{UEP} and \ac{EEP} on Video Data}\label{test:video}
In this section a test on how \ac{UEP} performs on actual video data is performed. This is done because the \ac{NC} is applied on each \ac{GOP} in the video, resulting in a varying generation size, as covered in Section \ref{subsec:gopdistribution}. The performance will be measured in the amount of frames in a video that is succesfully decoded.

\subsection{Testing Procedure}\label{videotestingprocedure}
The test of \ac{UEP} performance on video data is done locally on a single computer to sort out any undefined behavior of the network, and to keep the test under controlled conditions. Packet loss is then introduced after the test, under the assumption that packet loss in a network is independent and identically distributed.

%% WRITE WHY THIS IS AN ACCEPTABLE METHOD!!
The test is done by running a whole video through the implemented software several times with varying values of $\mathbf{\Gamma}$ in the \ac{UEP} setup. The values used for these in the tests are shown in Table \ref{tab:videotestsetup}.

\begin{figure}[h!]
\centering
	\begin{tikzpicture}[->=stealth',auto, semithick,]
	\tikzstyle{every state}=[rectangle, fill=white, text=black,minimum height=1.5cm, minimum width=2.6cm, node distance=3.2cm,align=center,font=\scriptsize]
		\node[state,initial] (GOP) {Gather new GOP\\into a generation};
		\node[state, right of=GOP] (encode) {Create linear\\combinations from\\layer chosen with $\mathbf{\Gamma}$};
		\node[state, right of=encode] (decode) {Decode linear\\combinations};
		\node[state, right of=decode] (log) {Save info:\\Packets needed\\for each layer\\to decode};
		
		\path (GOP) edge[->,shorten >=1pt] (encode);
		\path (encode) edge[->,shorten >=1pt] (decode);
		\path (decode) edge[->,shorten >=1pt] node[yshift=0.7cm] {\tiny{If GOP decoded}} (log);
		
%		\path (decode.south) edge[bend left] node[above,yshift=0.1cm] {\tiny{While not decoded}} (encode.south);
		\draw[-] (decode.south) -- ([yshift=-0.8cm]decode.south);
		\draw[-] ([yshift=-0.8cm]decode.south) -- node[above] {\tiny{While not decoded}} ([yshift=-0.8cm]encode.south);
		\draw[->,shorten >=1pt] ([yshift=-0.8cm]encode.south) -- (encode.south);
		
%		\path (log.south) edge[bend left] node[above, yshift=0.05cm] {\tiny{While video has not ended}} (GOP.south);
		\draw[-] (log.south) -- ([yshift=-1.5cm]log.south);
		\draw[-] ([yshift=-1.5cm]log.south) -- node[above,yshift=0.01cm] {\tiny{While video has not ended}} ([yshift=-1.5cm]GOP.south);
		\draw[->,shorten >=1pt] ([yshift=-1.5cm]GOP.south) -- (GOP.south);

	\end{tikzpicture}
\caption{5.2, Page 64}
\label{dummy}
\end{figure}

During the test, every \ac{GOP} in the video is packed into seperate network coded generations using \ac{EW} \ac{UEP} \ac{NC}. Because the I-frame data is considered of higher importance, it is placed in \ac{L1}, while P-frame data is stored in \ac{L2}. Some P-frame data may be included in \ac{L1}, because of the layer size limitations as mentioned in \ref{implementation:software:networkcoding:encoder}.
%the size of the layer (in bytes) has to be a multiple of the packet size.

\begin{table}[h]
\centering
\begin{tabular}{ c | c | c | c | c }
Test \# & Video ID & Layers & $\boldsymbol \Gamma_1$ & $\boldsymbol \Gamma_2$ \\ \hline
1 & C.2 & 2 & 0.30 & 0.70 \\ 
2 & C.2 & 2 & 0.35 & 0.65 \\
3 & C.2 & 2 & 0.40 & 0.60 \\
4 & C.2 & 2 & 0.45 & 0.55 \\
5 & C.2 & 2 & 0.50 & 0.50 \\
6 & C.2 & 2 & 0.70 & 0.30 \\
\ac{EEP} & C.2 & 1 & 1.00 & - \\
\end{tabular}
\caption{Settings for the tests of \ac{UEP} on video data. The video used (C.2) is described further in Section \ref{subsec:choosingsamplevideos}.}
\label{tab:videotestsetup}
\end{table}

Packets from layers chosen with $\mathbf{\Gamma}$ are then handed from the encoder to the decoder until the decoder is able to decode all layers in the generation. Information about packets needed for each layer to decode is stored, along with the layer sizes, generation size and generation ID. This process is illustrated in Figure \ref{fig:videotest_sequence}, while the data stored is illustrated in Figure \ref{fig:testing_results}.

\begin{figure}[h!]
\centering
	\begin{tikzpicture}[>=stealth',shorten >=1pt,auto, semithick]
	\tikzstyle{every state}=[rectangle, fill=white,text=black,,minimum height=1.3cm, minimum width=2.5cm, node distance=2.5cm,align=center,font=\footnotesize]
	% First loop
		\node[state, draw=none, font=\scriptsize] (info1) {Generation ID 90\\ Video-cycle 0 \\ $\boldsymbol \Gamma_1=0.30$};
		\node[state, right of=info1] (L1_1) {Layer 1\\ \tiny 2 frames \\ \tiny Size: 48 Packets };
		\node[state, right of=L1_1] (L2_1) {Layer 2\\ \tiny 20 frames \\ \tiny Size: 175 Packets };
		%\node[state, right of=L2_1] (L3_1) {Layer 3\\ \tiny 9 P-frames \\ \tiny Size: 10 Packets };
		\node[state, right of=L2_1, font=\tiny, draw=none, xshift=0.2cm] (ginfo1) {Generation size: 175 \\ Packet needed:\\ Layer 1: 149\\ Layer 2: 186};
%0, 80, 154, 1432, 2, 56, 154, 0, 148, 156, 0, 20, 3, 17, 0
	% Second loop
		\node[state, draw=none, font=\scriptsize, below of=info1, yshift=0.5cm] (info2) {Generation ID 90\\ Video-cycle 4\\ $\boldsymbol \Gamma_1=0.30$};
		\node[state, right of=info2] (L1_2) {Layer 1\\ \tiny 2 frames \\ \tiny Size: 48 Packets };
		\node[state, right of=L1_2] (L2_2) {Layer 2\\ \tiny 20 frames \\ \tiny Size: 175 Packets };
%		\node[state, right of=L2_2] (L3_2) {Layer 3\\ \tiny 9 P-frames \\ \tiny Size: 10 Packets };
		\node[state, right of=L2_2, font=\tiny, draw=none, xshift=0.2cm] (ginfo2) {Generation size: 175 \\ Packet needed:\\ Layer 1: 163\\ Layer 2: 185};
		
%11, 80, 154, 1432, 2, 56, 154, 0, 148, 156, 0, 20, 3, 17, 0
		
	% Third loop
		\node[state, draw=none, font=\scriptsize, below of=info2, yshift=0.5cm] (info2) {Generation ID 90\\ Video-cycle 41\\ $\boldsymbol \Gamma_1=0.30$};
		\node[state, right of=info2] (L1_3) {Layer 1\\ \tiny 2 frames \\ \tiny Size: 48 Packets };
		\node[state, right of=L1_3] (L2_3) {Layer 2\\ \tiny 20 frames \\ \tiny Size: 175 Packets };
%		\node[state, right of=L2_3] (L3_3) {Layer 3\\ \tiny 9 P-frames \\ \tiny Size: 10 Packets };
		\node[state, right of=L2_3, font=\tiny, draw=none, xshift=0.2cm] (ginfo3) {Generation size: 175 \\ Packet needed:\\ Layer 1: 153\\ Layer 2: 190};
		
%90, 80, 154, 1432, 2, 56, 154, 0, 148, 156, 0, 20, 3, 17, 0	
	
	\end{tikzpicture}
\caption{Illustration of how information about the packets needed for decoding each layer is stored, along with the size of each layer and the complete generation size. For \ac{EW}, the last layer in a generation will always be equal to the generation size. The information shown in this figure is actual data from test \# 1.}
\label{fig:testing_results}
\end{figure}

The process is done on every \ac{GOP} in the tested video, and this whole video-cycle is repeated 50 times for each tested value of $\mathbf{\Gamma}$. The amount of data processed throughout the tests performed is totaling more than 70 GB excluding overhead.

\subsection{Data Processing}\label{sec:testvideo_calc}
Instead of inducing a packet loss when handing the linear combined packet from encoder to decoder, data loss are introduced analytically after the testing described in Section \ref{videotestingprocedure} has finished. This can be done under the assumption that packet losses in a network channel are independent and identically distributed, and the fact that packets from the layers in the \ac{UEP} setup are chosen from a binomial distribution. 
Furthermore, every packet is a random generated linear combination of source packets.
Because of this, packets lost caused by erasures on the channel are expected to follow the same $\mathbf{\Gamma}$ distribution as the generated packets, and packets lost would not have influence on the received data, due to the packet being independently encoded. This is why packet loss can be introduced analytically.

The advantage of introducing packet loss analytically after the test is done, is that a great amount of data processing is avoided. Each repeated test for each investigated packet loss rating would require at least an extra 70 GB of data processing.

To evaluate the performance of the \ac{UEP} setup, the amount of frames the decoder is able to extract is reviewed for increasing packet loss. These are found by investigating which of the layers that was able to be decoded in each generation of each video-cycle. This is done for each analysed packet loss rating.

Due to the increased amount of information sent about the smaller layer, the needed overhead for successful total decoding varies when changing the values of $\mathbf{\Gamma}$, a shared overhead should be applied analytically to all tests of varying values of $\mathbf{\Gamma}$ for proper comparison. How this overhead is calculated and applied is covered in the following section.

\subsubsection{Applying Overhead}
The overhead needed for successful total decoding of each generation is calculated from the needed amount of packets and the generation size for each generation, in each video-cycle. The overhead for each set of $\mathbf{\Gamma}$ are shown in Table \ref{tab:videotestoverhead}. It is seen that the overhead is largest at higher values of $\mathbf{\Gamma}_1$, while the least overhead is needed by \ac{EEP}. This is fully in line with the analysis and simulations made in Chapter \ref{analysisofsolutions}, and greatly resembles the trade-off in overhead needed to do \ac{UEP}.

\begin{table}[h]
\centering
\begin{tabular}{ c | c }
$\mathbf{\Gamma}_1$ & Overhead \\ \hline
0.30 & 11.38 \% \\ 
0.35 & 17.79 \% \\ 
0.40 & 25.63 \% \\ 
0.45 & 35.57 \% \\ 
0.50 & 47.62 \% \\ 
0.70 & 138.69 \% \\ 
\ac{EEP} & 2.36 \% \\ 
\end{tabular}
\caption{Overhead needed to decode the entire video for each tested value of $\mathbf{\Gamma}$ for the \ac{UEP} setup.}
\label{tab:videotestoverhead}
\end{table}

To compare the tests of varying values of $\mathbf{\Gamma}$, a shared overhead should be applied. Though, it would be extreme to apply $\approx$140 \% overhead to satisfy the needs of $\mathbf{\Gamma}_1=0.70$. Because of this, a shared overhead of 40 \% is chosen. In the investigation of decoded frames and packet loss, this choice of 40 \% shared overhead will cause the tests of $\mathbf{\Gamma}_1=0.50$ and $\mathbf{\Gamma}_1=0.70$ not to be able to decode all \ac{L2} data at all times. Though, 40 \% is considered an acceptable increase in channel occupancy.

This shared overhead is added to each of the generation sizes before introducing a packet loss. This is described in the following section.

\subsubsection{Extracting Decoded Frames}
After the overhead has been applied, packet loss can be applied gradually. For each new increase in packet loss, it is investigated whether each layer in each generation could be decoded.
The algorithm that decides whether a layer could be decoded or not applies the inequality presented in Equation \eqref{eq:successdecode}. If the inequality is true, the layer can be decoded. This is done for every generation in every video-cycle, for every value of $\mathbf{\Gamma}$, every time the packet loss is increased.

\begin{align}
P_i &\le G \cdot (1+O) \cdot (1-L) \label{eq:successdecode} \\
\intertext{Where:} 
&\text{$P_i$ is the packets needed to decode layer $i$.} \notag\\
&\text{$G$ is the generation size of generation containing layer $i$.} \notag\\
&\text{$O$ is the shared overhead expressed as a decimal number, $O\ge0$.} \notag\\
&\text{$L$ is the introduced packet loss expressed as a decimal number, $0\le L\le1$.} \notag\\ \notag
\end{align}

When a layer is considered to be able to decode, the amount of frames contained in that layer is noted. The total amount of decoded frames is then compared with the total amount of frames to get an expression of how many frames that was actually decoded. For every value of $\mathbf{\Gamma}$, this gives us the results shown in Figure \ref{fig:test_video}. These are discussed in Section \ref{test:video:results}.

\subsubsection{An Example}
Figure \ref{fig:testing_results} can be used as an example of how this decision process functions. Figure \ref{fig:testing_results} shows three video-cycles of the generation with ID 90, which holds 20 frames: 2 frames in \ac{L1}, 20 in \ac{L2} (\ac{L2} has all the frames). The I-frame data is located in \ac{L1}\footnote{The software implementation makes sure the I-frame is in the layer of highest importance.}, along with a P-frame. With a generation size of 175, a shared overhead of 40 \%, and a packet loss of e.g. 10 \%, 233 packets are ''received''. This is plenty for both layers to decode in every video-cycle shown in Figure \ref{fig:testing_results}, where a maximum of 190 packets was needed to decode. However, a packet loss of 33 \% would give 173 ''received'' packets. This means that \ac{L2} would not be able to decode, while \ac{L1} has enough packets to decode. As a result, only two frames could be decoded with a packet loss of 33 \%. This might not be much, but it is important to note that the I-frame is preserved, which means that proper, error free data can be presented on the screen, due to the independent nature of I-frames.

For comparison in this simple example, \ac{EEP} would require at least 175 packets to decode\footnote{This is also the case with the actual test data.}, which means no data can be extracted using \ac{EEP}, thus no video data can be presented on the screen.


%M, Generation, Generation size, Symbol size, Layers, Layer 1 size, Layer 2 size, Layer 3 size, Received packets from layer 1, Received packets from layer 2, Received packets from layer 3, Total frames, Layer 1 Frames, Layer 2 Frames, Layer 3 Frames

